Europaisches Patentamt 

© European Patent Office ® Publication number: 0 274 406 

Office europeen des brevets ^2 



@ EUROPEAN PATENT APPLICATION 

® Application number: 88300017.6 ® Int. CI. 4 : G 06 F 15/16 

@ Date of filing: 05.01.88 



@ Priority: 05.01.87 US 621 

@ Date of publication of application : 
13.07.88 Bulletin 88/28 

@ Designated Contracting States: DE FR GB 



@ Applicant: COMPUTER X, INC. 
1201 Wiley Road Suite 101 
Schaumburg Illinois 60195 (US) 

@ Inventor: Simor, Gabor 
460 W. Oakwood Drive 
Barrington Illinois 60010 (US) 



@ Representative : Hudson, Peter David et al 

Motorola Patent and Licensing Operations - Europe Jays 
Close Viables Industrial Estate 
Basingstoke Hampshire RG22 4PD (GB) 



@ Self-configuration of nodes in a^distributed message-based operating system. 

(g) In a distributed system comprising a plurality of nodes 
{170-174, FIG. 7), each node is provided with the same set of 
generic configuration rules which configures the resources for 
the node according to the application requirements and the 
hardware configuration of the node. The resource server 
modules (231-234. FIG. 8) are configurable at run-time by 
node-based configuration management processes (230) in 
accordance with information contained in resource definition 
messages. A resource definition message is derived from a 
resource template message in accordance with the information 
contained in the node definition message. Accordingly, adding 
or modifying resources at a given node can be accomplished at 
start-up or at run time without affecting the remainder of the 
system. 
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Description 



Self-Configuration of Nodes in a Distributed Message-Based Operating System 
RELATED INVENTIONS 

5 The present invention is related to the following inventions, ail filed on May 6, 1986 and al! assigned to the 
assignee of the present invention: 

1. Title: Nested Contexts in a Virtual Single Machine 
Inventors: Andrew Kun, Frank Koinick, Bruce Mansfield 
Serial No.: 730,903 

10 2. Title : Computer System with Data Residence Transparency and Data Access Transparency 

Inventors: Andrew Kun, Frank Koinick, Bruce Mansfield 
Serial No.: 730,929 

3. TitIe: Network Interface Module with Minimized Data Paths 
Inventors: Bernhard Weisshaar, Michael Barnea 

15 Serial No.: 730,621 

4. Title : Method of Inter-Process Communication in a Distributed Data Processing System 
Inventors : Bernhard Weisshaar, Andrew Kun, Frank Koinick, Bruce Mansfield 

Serial No.: 730,892 

5. Title : Logical Ring in a Virtual Single Machine 

20 Inventors : Andrew Kun, Frank Koinick, Bruce Mansfield 

Serial No.: 730,923 

6. Title: Virtual Single Machine With Message-Like Hardware Interrupts and Processor Exceptions 
Inventors: Andrew Kun, Frank Koinick, Bruce Mansfield 

Serial No.: 730,922 

25 The present invention is also related to the following inventions, all filed on even date herewith, and all 
assigned to the assignee of the present invention: 

7. Title: Computer Human Interface Comprising User-Adjustable Window for Displaying or Printing 
Information 

Inventor: Frank Koinick 
30 Serial No.: 000,625 

8. Title : Computer Human Interface With Multi-Application Display 
Inventor: Frank Koinick 

Serial No.: 000,620 

9. Titfe: Object-Oriented Software Architecture Supporting Input/Output Device Independence 
35 Inventor: Frank Koinick 

Serial No.: 000,619 

10. Title: Process Traps in a Distributed Message-Based Operating System 
Inventors: Gabor Simor 
Serial No.: 000,624 

40 12. Title: Computer Human Interface with Multiple Independent Active Pictures and Windows 

Inventors: Frank Koinick 
Serial No.: 000,626 



TECHNICAL FIELD 

45 This invention relates generally to digital data processing, and, in particular, to a distributed operating 
system which configures the resources required for each node in real time. 

BACKGROUND OF THE INVENTION 
The present invention is implemented in a distributed data processing system - that is, two or more data 
50 processing systems which are capable of functioning independently but which are so coupled as to send and 

receive messages to and from one another. 

Local Area Network (LAN) is an example of a distributed data processing system. A typical LAN comprises a 

number of autonomous data processing "nodes", each comprising at least a processor and memory. Each 

node is capable of conducting data processing operations independently. In addition, each node is coupled 
55 (by appropriate means such as a twisted wire pair, coaxial cable, fiber optic cable, etc.) to a network of other 

nodes which may be, for example, a loop star, tree etc, depending upon the design considerations. 
As mentioned above, the present invention finds utility in such a distributed data processing system, since 

there is a need in such a system for processes which are executing or which are to be executed in the 

individual nodes to share data and to communicate data among themselves. 
60 A "process", as used within the present invention, is defined as a self-contained package of data and 

executable procedures which operate on that data, comparable to a "task" in other known systems. Within the 

present invention a process can be thought of as comparable to a subroutine in terms of size, complexity, and 

the way it is used. The 'difference between processes and subroutines is that processes can be created and 
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d ther "subroutines*.. 

every process also has a known system-wide. the cont ext. 

10 r onSt P^I^S^SlSlf and to each other. Great, 

which it creates are known only me ^ ^ , ^ ^ Resting allows the 
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BRIEF SUM MARY OF INVENTION & dsvi ^ " to ™ 

Accordingly ; t is , n 'r! vl:N 'ION 
'gating .JJJ," 30 <*J«« of the present t 

" ,s a/so an object of th P dS a da,a Processing svst Pm h ■ 

gating system SXs?^ invention to p roWde an . ' ^ ^ a " im proved 

n These and other obS a ° f ,he s ^te m * 3 SJVen at start-up «S £ S 9 a " 0perati r>3 
Priding in a dfstnC J d e 2 ta ? rn acf,tevBl ' in accordance with rUn " time W ' thou ' 

e^pescmmoN of the n B resource type ne S byXT'T definiti '° n 

. invention is pointed DRAWINGS V the s P ec,f 'c node. 

s*v e , „<,„„,, "» <tagram fo, m „ ow R »"•■ '« S«o urce Ssrvar 

Environment 3 fhwc ^ i„ ustrating a modu(e 0eftn *°" ^sage from Resource 

area network LAN ? ~° G - 2 ' a mu '«P'e-netw 0 rk d,^ •„ ^ dU ' 6 13 ' other 

UN 2 may com p rise severa( p ^ and/or ' e rnote processors ? S uTa n s ' Cat, '° nS Mod "' e 

'he P r esent invention or * des (not s hown) and m Programmable 
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LAN , is additional* coup.ed to a third loca. area network LAN 3 via .CM 52. A process control 55 is a,so 

Tlfprese^etrN 5 ^ RO. 2) comprises ^ ^ ^^-^ 
processor from the Motorola 68000 family of proc ess odeJJ & (nterface 

(ROM) 28 and a random access ^Se U and a Bus Interface 29. which couples the node to 
Module (N1M) 21. which connects the node o »e ana * rting ^ peripheral devices, such 

additional devices within a node. White a minimal node, s capable pp g iudjng 

as an Operator Display Module gODM .4 and ^ e a d n ^ hj M f^ tn e r additional devices may comprise, f^ 
SSS a ^rL^^^ supports a hard disk and a back-up device (floppy 

disk or streaming tape drive) . t,«, whna ,H an d screen to enable an operator to input information 

The Operator Display Module 41 provides a keyboard and screen 10 

and receive visual information. . , application individual nodes will 

While a single node may comprise a II of ^/^^ mass sior^e nodes maybe set up 

normally be dedicated to specialized factions. For Xor consoie s and at. lost one node for 

JESS Z^X^SX ™Ls° P or separate dedicated nodes, may execute 

Pa T sysStl iW-Kp- - provide an in^ted -^S^^J^ 2*. 
acquisition, and other real-time applications As ' 9 "= h - d ^" de |,J ctronte mail, event recording, and file 
^^^^ SZsSZ carers, a window-oriented editor, a debugger, and 
performance-monitoring tools. 

Local Area Network 2 t , the entire system together and makes 

The local area network, as depicted in e.ther FIG.1 • Jhe ^ jdes hign thr0U g hpu t, 

possible the distributed virtual m " h,ne .^ t d *"™N ,s also autonomous, in the sense that all system 
guaranteed response, reliability, and low entry ^ S J" Net work Interface Module (e.g. NIM 21 . 

and applications software is unaware of its je*'^^ j «a m Ple a y ^ ^ j{ 

FIG. 2) could be replaced without ^'"^ so^nj ^ cab , e . Two channels (logically, two distinct 

The LAN interconnection medium may be twisted-pair or coaxial cao 
networks) may be provided for -liability and for n ;j^ c ^^^p« M dfrom rnxletonod. 

a /h^ P r=r 

du.l-port.d butter pool whicr, conuin. . W« < <* °^™<. ,.a,sembl.d By the reo.Mng NIM. Ftantes 

same LAN protocol via so-called "bridgeways . or it may be connect 4 
Software Model nro =«nt invention operates upon processes, messages, and 
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p?ovides quick dtrect access ' " " 

name has a limited scope and provides fy^. 1 ^ ^'^res^t intention is shown. The bottom, or hardware. 

With reference to FIG. 3, an architectural model of the P.^ nt in ^ essors 71 . ?6 may exjst 

tayer 63 comprises a number of processors 71-76 as f"escriD n(jmber Qf sses P1 . P10 

physically within one or more nodes. The to •°^^;'^ r 6i labelled 'virtual machine", isolates the 
which send messages m1-m6 to each other. Tn ^ m ' d J le ^n , as if they were going to be executed on a 

S"so~^^ mU ' tiP,e P " Wrth ° Ut ^ 

explicitly designed for that purpose. 

The Virtual Machine . „„„ t=i „ or i nackaae of data and executable procedures which 

As discussed earlier, a "process" is a s ^ onX ^f?^tf°^° ssed by other processes. There is no 
operate on that data. The data is totally P^^^^^^cesa is strictly sequential. Multiple 
concept of shared memory within the present .nvention. Execution ot a pr 
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ESSE ° Perating SySt6m - The « be 

Every process has a uniq J "orocM, i2„?r k eV6n lf multi P le instances are active 

assigned by the system ^r^^^^^^^fj^ by 'J** il can be ^ferenced. The PID is 
PID assignment contains a random!™ ?actor whS n rema,ns ' n e ! ect unfil the P roc «s terminates. The 
future. The contents of the P n » ™ IZ, ' T ?" 9 uarantees Wat the PID will not be re-used in the near 
physically .ocate the process. A W^Xc^^T?'^™ ^ * V the VirtUal machine to 

Every process also has a "rami- I h 9 pointer" to a process, 

programmer. A name need not be ^J^^JTT^ ^ * ehmStan aSsi 9 ned by the 
and to aid in fault-tolerance. Q " th ' S ambl 9 uit y ma V be used to add new services transparently 

"coS^Sed^ ^^S^^SST i ?°, diStinCt * means of 

names are not known outside of the context Context a °°fP^ ^ Passes whose 

a. Context 91 contains processes B a T r a 'J example, conta.ns processes A, a, a, b, c, d, and 

One particular process In each ^le^ed t^anL^T** 92 . C ° nta '' nS ^^^Tc- d and x 
within the immediately enclosing cS^u^^^^^^f^ b ° tn Witni " ^text an*d 
processes A-C are context processes for context! 90 s?TJn t . ^ thB eXample il,Ustrated in F| G- 4. 
context 90, and the parent context of ™ZZ?£^rt3 9 ?!^ lV * y - , The P arent cont ^* <* context 91 is 
the boundary of the context and acts as a gate IntoT Conce P tua "y. *e context process is located on 

P^S" 

Processes in context 90 can only access pUSh"^^^^ 

* ^Ssef^~ 

constructed. A context must reside cTmiTeteK o ™J w ^ ' 8 ° f a ^traction S to be 

all-encompassing context which is always p Te S f^^ System is tre ^d as an 

contexts define localized protection dnmlfnc t ? S the n ' 9hest levei in tne hierarchy. In essence 
conflicts. Protect™ doma.ns and greatly reduce the changes of unintentional nam,ng 

-h^^^ "^"^ to one inside another context by 

Most process servers within the oresent invIS^ f ♦ ° U9 u ° n6 ° r the 0ther of the con text processes 
desired function (such as a window Z° Sta^TdM^ ^ ^ ^ aCC6SS is «* name 'Once the 
via PID's. ° r r " e ' 15 opened • tne us er process and the service communicate directly 

inforS^ 

and the sender's PID. By convention fte irJS^n JmSc P™^™"^ contains the destination name 
type of message (e.g.. "read", "stags' VZ ^saalsZ T h ™ ; terminated strin 9 which defines the 
sent. Queuing ensures serial access and is ,,«r??n / q U6d f ° the receiv i n S process when they are 
<0 Messages provide the mechanism bv wht h m preference to semaphores, monitors, etc. V 

anywhere in the virtual macMne caTsenS a iTssaaeT^ • ta achtev8d - A process '°«t-d 

applies with some restrictions across briSgewayslfe ?heZ25?r ^T* « '! name ' Tra nsparency 

network protocols) and in qeneral not«H«^ * " lnterfaces between LAN's operating under identical 
different network protc^nuTCn^ J'aES f MwWn ^ N '^P^ating unde 

upontte required level of performancT degradation. However, they could so operate, depending 

virtuaTmaS ™nts to processes will now be described. The 

device 101, the virtual machine kernel fifj? ' F ° r exam P ,e ' wh en an interrupt occurs in an external 

an "externa, event servTc process" (EESW Sn^'^lT 8889 1 ° 3 1 ° 3 SpeCifiC process 
pre-allocated once and circulates bKT^ 

-nformation to indicate the occurrence tffa wnf™* St* Z*™ 1 J" 8 meSSage COntains ^enough 
to the event, such as setting contro^d^ 

messages from the user process 106 " etc IS ? ° l U8er PTOCeSS 106 ' tra nsmitting -Read- 

To become an EESP a Dmrocti - n re,easln 9 the interrupt. y 

must execute a "disconnect be ore"'? Mte^J?^ th6 appra P riate device register(s). It 

protoco, between EESP's and -PP^!^^ -*« «- -sige 
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Inter-Process Communication 

0^.™^^^ 1^7^^ ^T^' m ° Sf ° f the Virtual ma =h'ne primitives are 

ALLOC- requests alloca ? on o? a ^messlae, I T« "T^™ ^ pM&S are the fo,lowi ng 

FREE- requests deallocation L {messa 9e) buffer of a given size. 

put „nw = oeauocation of a given message buffer 

GET. S a o^^ a t0 3 9^n destination (b? name of PID). • 

FORWARD. ^ a r"S d ;^^^^^^o m a specific process (by P, D ). 



6 



0 274 406 



10 



IS 



25 



30 



CALL - send a message, then wait for and dequeue the reply. 

REPLY- send a message to the originator of a given message. .... ,. „ „ ., „ 

ANyLmsG- returns "true" if the receive queue is not empty, else returns false ; optionally, checks rf any 
messaqes from a specific PID are queued. 

To further describe the function of the kernel primitives. ALLOC handles all memory allocates. It returns a 
pointer to a buffer which can be used for locai storage within the process or which can be sent to another 
process (via PUT, etc.). ALLOC never -fails", but rather waits until enough memory is freed to satisfy the 

re The%7-primitive queues a message to another process. The sending process resumes execution as soon 

* & FORWARDS useTtoquickly reroute a message but maintain information about the original sender 
(whereas PUT always makes the sending process the originator of the message) 

REPLY sends a message to the originator of a previously received message, rather than fay name or PID. 

CALL essentially implements remote subroutine invocations, causing the caller to suspend untt tne receiver 
executes a REPLY. Subsequently, the replied message is dequeued out of sequence, immediately upon 
arrival and the caller resumes execution. ' . * • „ , u 

The emphasis is on concurrency, so that as many processes as poss.ble are executed in parallel. Hence 
neither PUT nor FORWARDS for the message to be delivered. Conversely. GCTsuspends a process unt.l 
^message arrives and dequeues it in one operation. The ANY-MSQ primrtive .s provided so that a process 
may determine whether tSere is anything of interest in the queue before committing itself to a GET. 20 

When a message is sent by name, the destination process must be found in the name space. The search 
path is determined by the nesting of the contexts in which the sending process resides. From a given process, 
a message can be sent to all processes in its own context or (optionally) to those in any higher context. Refer 
to FlS 6 The contexts are searched from the current one upward until a match ,s found gr unt.l the system 
context is reached. All processes with the same name in that context are then queued a copy of the message 

For example with reference to FIG. 6, assume that in context 141 process y sends a message to ALL 
processes by the name x. Process t first searches within its own context 141 but finds no process x.The 
process y searches within" the next higher context 131 (its parent context) but again finds no process x. Then 
p ocess y searches within the next higher context 1 10 and finds a process x Identified by reference numeral 
? 2 since it is the only process x in context 110, it is the only recipient of the message from process y. 

If process atn context 1 31 sends'a message to ALL processes by the name x rt first searches within rts own 
context 131 a'nd finding no processes x there, it then searches within context 110 and finds process x. 

Assume that process b in context 131 sends a message to ALL processes by the name A. It wouid find 
process A (111) in content 110. as well as process A (122) which is the context process for context 121. 

A process may also send a message to itself orlo its context process without knowing either name 35 

^concept of a "logical ring" (analogous to a LAN) allows a message to be sent to the /V^process in the 
system with a given name. The message goes to exactly one process in the sender's context, rf such a process 
exists Otherwise the parent context is searched. ^ *u * 

The' virtual machine guarantees that each NEXT transmission will reach a different process and that 40 
eventually a transmission will be sent to the logically "first" process (the one that sent the original message) in 
the ring completing the loop. In other words, all processes with the same name at the same leve can 
communicatTwith each other without knowing how many there are or where they are located. The logical r.ng 
is TssenlS fo-7 distributing services such as a data base. The ordering of processes in the ring ,s not 

^Fofe^ample if process a (125) in context 121 sends a message to process a using the NEXT primitive the 
search S a f'i st P rocess-a (124) in the same context 121 . Process a (124) is marked as .having received the 
message and hen'procesi a (124, sends -the message on to the NEXT process a (123) ,n cpntext t21_ 
Process a (123) is marked as'having received the message, and then ,t sends the message i on , to the . NEXT 
process a, which is the original sender process a (125). which knows not to send rt further on, s.nce ,t s been 
marked as having already received the message. 

Sending messages directly by PID obviates the need for a name search and ignores context boundaries 
Thfs is IncZ as the DIRECT mode of transmission and is the most efficient. For example, process A (111) 
sends a message in the DIRECT mode to process y in context 141. 

If a process sends a message in the LOCAL transmission mode, it sends .t only to a process having one 

^summar? iS^^EC^SL^ mode, there are five transmission modes which can be used 

22 To wShThe ^SSTS. first context which contains that name, starting with the 

sender's context and searching upwards through all parent contexts. 
LOCAL - to ail processes with the given name in the sender's context only. 

NEXT- to the next process with the given name in the same context as the sender, rf any; otherw.se it 
searches upwards through all parent contexts until the name is found. ^ Pr « nnnri i„n tn th« 

LEVEL - sends to "self" (the sending process) or to "context- (the context process corresponding to the 
sender's context); "serf* cannot be used with CALL primitive. 
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DIRECT- sent by PID. 

Messages are usually transmitted by queueing a pointer to the buffer containing the message A messaae is 
only cop.ed when there are multiple destinations or when the destination is on another node. 

. Operating System 

rf 0 Swhow er f nQ T tem ° f the Present invention consists of a kernel, which implements the primitives 

?At tl S° f ' P S f S , 8t °L Pr0CeSS6S Which provide process creation and termination, time management 
(set time, set alarm, etc.) and which perform node start-up and configuration. Drivers for devices are also 
implemented as processes (EESP's), as described above. This allows both system services and device driers 

L^^pZSEnt Sare" 8 ° Peratin9 ^ 3,30 SWaPP, ' n9 ^ 

Unlike known distributed computer systems, that of the present invention does not use a distinct "name 
mud! taste? 888 ^ nameS ' Name Searchin 9 is confined to the kernel - wnicn has «« advantage of being 
A minimal bootstrap program resides permanently (in ROM) on every node, e.g. ROM 28 in node N of FIG 2 
In k °! S j- aP Pr0 ? ra T executes automatically when a node is powered up and begins by performing basic 

th^iiT 08 *' 03 !* th8n , att6mptS t0 find and Start an initial system code module The module is sough? on 
the first disk drive on the node, if any. If there isn't a disk, and the node is on the LAN, a message will bfsent 
out requesting the module. Failing that, the required software must be resident in ROM. The initialization 
JJSSsT S8tS UP a " kerne '' S intema ' tabl6S and th6n CallS a P redefi "ed entry point of the 

Thus there is no well-defined meaning for "system up" or "system down" - as long as any node is active the 
3£5 m aS f h who1 * may ^considered to be "up". Nodes can be shut down or started up dynamically without 
^Tcln^nZ* ° n ThS SamS Prindple appMeS ' in a ,imited sense ' ^ Peri P hera.s. y Devfcss 

Standard Message Format 
FIG. 6 shows the standard format of a message in a distributed data processing system of the tvoe 

'Zes'ls? si P Z 8 i\ ^"h 0 "- Th l mSSSage f ° rmat C ° mpriSeS 3 messa 9 e id " portion 150 = °™ " mi™ 
fleMs such as Sid! ! 156-158 end -° f - messa 9 e portion 16 °- Each "triple" comprises a group of three 

The first field 156 of "triple" 151, designated the PORT field, specifies that the data field represents the name 
SfisTeTatafield 0 ' 63 * ^ SeC ° nd ^ 157 °' 151 giV6S the SiZS ° f the data f » e,d - The third «^ 

The first field 159 of "triple* 153, designated the PNTF field, specifies that the data field represents the name 
of the process to notify when the process specified in the PCRT field has been created 

comaTnlna a pS R T a n^T7f n M mb8r °' " triP ' eS "' and there Can be mU,tiple " trip,es " in the same ™ssage 
containing PORT and PNTF fields, since several processes may have to be created for the same resource 

As presently implemented, portion 150 is 16 bytes in length, field 156 is 4 bytes, field 157 is 4 bytes field 158 
is variable in length, and EOM portion is 4 bytes. 

Resource/Connector Model 

u tI h B e ,S!=. bUted h SyStSm - °l L he Pn5Sent invention mav be vi ewed at several levels of complexity. The base level 

4struc^ns^ a i C p th T Ch f" 63 3nd im P |ements the device-independent architecture consisting of virtua 
instructions , i.e. the kernel primitives. 

nro7r!™ lT?nT iV ab ° Ve i his - and c,oselv relat ed to it, is the process/message model which defines how 
programs are configured in the system and how they communicate with each other 

Just above this level is a more abstract model dealing with "resources" and "connectors". As mentioned 
ea her, resources may be thought of as "logical devices". Resources are accessed through "co™ecto?s" 
which are essentially logical "pointers". ^uneoiors , 

.oSntnf?" mUSt hSVe 3 connector to a resource in order to interact with it. Connectors are granted and 
resources. reS ° UrCe mana9Sr pr0CSSSes "' i e " Presses which can be requested to create delete !tc 
Resource manager processes, respond to connector messages to "create" new resources and "delete" old 
connection fox" *" SXiStin9 reS ° UrCe ( '" -e " ^ ^ * COnneCtion t0 il) and laterto " close " " (terminated 

™IX„T ap0n8e - t0 Cr ! ating a resource - or 0 P eni ng a connection to it. is a connect message. This messaae 
contains a service-independent connector data structure which uniquely identifies the resource 
3n l^ ' C at '° n mav create a new resource, or acquire access to an existing one, by making a request to the 
appropriate resource manager process. (Note that all resources remain controlled and protected by he 

r JZZ f , T a9er Pr ° CeSS ' and th6y are kept in its context -> As a result, a connector to the resource is 
rnnZ ? application, allowing it to communicate directly with the resource. Note that, in general two ■ 

reS ° U " e mana96r PrOCSSS ' and ° ne f0r the resource (a«thou 9 gh?n ma" " . 

cases tne resource manager process can be accessed by name). • ; ; 
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*-f a e o ^n^rific resource to which the receiving process 
When a connector is received in a message. . 'J n f s a spec^ esou c ^ ^ ^ 

has access. The entire connector must be . copied into £J of the connector . As mentioned 

messages themse.ves are usually sent ,n direct ™ od !;^ s ^ h ^appropriate, or via an explicit connector 
above, messages to the resource's manager can be sent by name, i w w 

(to the manager), if available. mQ „ a „ or nrocess usually expect a process name as a 

Both "create" and "open' requests to the resource .^f^^^ut a na P me causes the service to 
parameter, and both return a connection message A create ^ J^rt o ^ 
generate a unique name. An -open" n ^^^^%^CB^i'deiBte' and "close" requests may 
the resource differently or to gain access to a closely rela ' e h d /"°" r " e name 
accept either an explicit connector to the source or he ^obs^^ 

There are five formats for connection ^^:"^^^SSe\^h requests that a specified 
"open", which establishes a connection to an ex sting ™s°" ce - a ™ tne connection to a resource be 
resource be removed from the system, close ^ 7^^ The -connect" message normally 
terminated; and "connect", which provides a ^onnecton tQ -a resource. unsolicited, 
represents a response to a "create or open ? ne dist ributed system of the present 

JZS^~Z^ TaZZX?™' message. Oata is requested by the "read- 
message (to which "write" or °J a * led " ar f, th ^™d ^fh°fanld- to "write" requests. Conversely, a write-only 
Process which only generate data s ^ M ^ ond ^J^uX a data "triple") if it receives a "read" request, 
resource should return "no data" (i.e. a "wrrte J™^ 8 .^ used to send data; and "read", which 

There are two formats for data exchange messa ge ™f u ™™ £ e data, the destination resource, the 
is used to request data. A "write" messa tge unc udes he ^ce <J Jhe . a ^ ^ 
originator of the data, the type of data (rf known ). , and pontons ™c ^ ^ . & ^ 

-query" or as the result of an asynchronous condition. 

DETAILED DESCRIPTION OF THE INVENTION 35 

Resource Template Messages snd Resource OsfinWor , Mes sages ^ compris es a set 

in the distribution system of the present invent.o .there , are °« e ^ m ° r ° contro|s one or more particular 
of Resource Server Modules. A Resource Server Moduta^s a P£« ss ^ tnQ form of a data manager , 
resources of the same class. For example a R 8 . 90 "^.^^ "°° u message server, debugger, console 
human interface manager, network Interface rno^ Module is run . time 

manager, event manager, command line tnterprjter e c ^ Res M _ 

configurable in accordance with ^^f"^ manager process described above in the 

A Resource Service Module consists of; a t leas t on Resource manag P Qf ^ node 

section entitled "Resource/Connector Model , and , is > also J™ 9™ , b , e for autonomously configuring 
which is controlled by Resource Definit.on Messages ^;^ S ^^ of the main resource manager 
and controlling further possible processes wrthin or outside of the co 
process if it is necessary for serving the particular class of c resour ^ 0 

The Resource Server Modules are themselves created by a Con figuration m g ^ Rea0 urcB 

each node. It is the responsibility of the Configurate >^°^£J^££° ne Definition Messages to the 
Server Modules for its node, and to? om ^ a '^^*l^™%!£ requirements. 
Resource Server Module in accordance w .th th^ 

A Resource Definition Message ,s what provides all of he attribu tes on ^ ^ ^ ^ 

all relevant attributes of the running ^^^^^^Zircs Definition Messages is derived 
resource and tells the Resource Server Module what to do. Each Hesource 

from a Resource Template Message. att rihi.t*»s of a resource for all node environments that 

A Resource Template Message is what defines the attributes of a res ° ur J , d | nformatlon for 

are reasonable to expect. Resource Template Mew conttm £ is a generic form 0 f 

AX5 ™ — — - - entire 
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These attributes control the implementation of Resource Definition Messages from a Resource Template 
Message by the Configuration Management Process. 'empiate 
rJ„ h x,,^ nfl9Urati0n Contr °' Attributes and their meanings are given as follows- 
cflor^-7,;t he W k '? 0le resource is conditional on a Node Definition Message attribute 
attrST Definition Messa 9e attribute value is to be used as a Resource Definition Message 

fttribSef ^ ' 3 ReS ° UrCe Definition Message attribute has values conditional on Node Definition Message 

^RESS/N^Tnnp^f 0 f t e ! S t0 bS USSd 33 ReS0Urce Definition Messa S e attribute val ^ 
address ^DRESS- the whole resource is conditional on the existence or absence of a given bus 

q\^nntme° PROC£SS ~ the whole resource is conditional on the existence or absence of a process with a 
CREATE RSM - create a Resource Server Module 

r?HnA, RS >u' Send thiS Resource Definition Message to a Resource Server Module 

t f Resource Server Module has to be transparently accessible in the network- if set the 

Srth?RVirn e ?r t0 A hiS reS ° UrCe C3n be re °- uested ^Vwhere in the network where needed 

™£aT™J Resource Definition Message is the header of a group of resources 
on ™T<Ji? t Resource Template Message attribute to pool resources into a group 
20 OPTION- tells what to do if the resource service cannot be started 

UP EVENT- an attribute for reporting resource service availability 

SYNCH- another resource type which the resource service depends upon 

PR^C%ES^% S ^ STITUTE i CONDITION ^, FILE, ADDRESS, NO ADDRESS, PROCESS and NO 

25 ZcSfo oLfnVfLT thS ™ st , important ' and thSy are USed by the Configuration Management 
d5 Process to convert the Resource Template Messages into Resource Definition Messages. 

Node Template Messages and Node Definition Messages 

n r r j ode ( , j( Definiti ° n Message describes the concrete node environment. Generally, there is one Node 
Def.nrt.on Message for each node. Node Definition Messages are structured identically to Resource Definition 
30 Messages and Resource Template Messages. uerin.uon 
A Configuration Management Process composes and sends the appropriate Resource Definition Messaaes 
n^m 6S0UrCe ? 6rVe , r M ° dUl6S in accorda "<=e with the informational content of a Node DefinWon MSSJe 
Nod?De;i S n ^ r nM p e ,? late f T? 9 ^ ^ ^ ^ Confi 9- ati ° n Management Process on each node reads the 
« 111 Def.nrt.on Message for that node, as well as all possible Resource Template Messages, and it generates 
35 the Resource Definition Messages for that node. generates 

u!l G ' 7 Sh t °n S h ° W Resource Template Messages, Node Definition Messages, and Configuration 

nod n es 9 170 e i7^ I? T ""T* ,nVBnttan - ^ 7 Sh ° WS 3 diStrib " ted ^stem compS ng 
nodes 170-174. Other nodes may also be coupled to this network, as represented by dotted connection 175 

Each node requires one or more resources to support it. During the configuration of, for example node 171 a 
Configuration Management Process (CMP) resident at node 171 utilizes one or more ReswrcS Template 
^s S o S ur S c e e S SL ' ^ d f D ^finition Message (NDM) and generates Resource Definition Messages^ Te 
Resource Server Modules (RSM) also resident at node 171 

J^fin 6 ^ 3 ReS ° Urce D 5jnition Message looks almost like a Resource Template Message, except that 

at rihntl^n th I 6 '? are d ! fferent - This is because the values in certain fields are conditional upon node 

mSL n r v ?f Def ' nlti0n MeSSage ° r Up0n the content of s P ecified fi,es in the file system 
Node Def.mt.on Messages can be derived from Node Template Messages, just as Resource Definition 

at^hT *™ d *^ Template Messages. A Node TemplateMessage is the generaSon of 

2lf e^lt£ it^ nrt0n K Me88afl93 0,8 SyStSm - ' n thiS Way severa ' ^rcnical laye s o 
50 whereas fn he LniM, ^ 9 Ca " bS bU,,t ln thS b0tt0m layer there are elementary resources, 

50 whereas in the higher layers more complex resource clusters can be configured 

ResouTcf De e f?nmon V M a p n « d ^ acc ° m .P an y in 9 ^charts shown in FIGS. 9A-9D and described hereinafter, 
uf" a . Definition Messages are derived by making checks and substitutions from Resource Template 
S es and a N ° de Definition Message. Using appropriate knowledge engineering techniques an expert 

55 ?SZ h k t0 d6riVe ReS0UTCe Definiti0n Messa 9 es from mor * com P' e * f°rn?s of Resource 

55 Templates and by also mak.ng inferences at run-time in additional checks and substitutions HeS ° Ur ° e 

JrslT Re t sourc ^. Tem P |a te Messages and Node Definition Messages themselves can be generated bv an 

coTu a^ioTof rZTl** M ^ * ™" ° f ^W^on expert system heira'rchies withthe 

teveS resources at the bottom level and configuration of product design at the higher 
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Module IS IT ff am f ° rm h ° W Resource Definition Messages are generated to a Resource Server 
frnm J v t r 9 , . '°. n Mana 9ement Process 230 utilizes a Node Definition Message (which may be derived 
ReT™ n r7 t A Mess ^ and a quantity N of Resource Template Messages to generate a quantity M of 
the Zs^rfnJ? n , Me f a 9 es < M alwa y s b ^ng less than N). Then a Resource Server Modules 231-234 use 
In SlrS m Def,n, ''° n Messages to configure the various nodal resources. Examples of these modules are 
an Event Manager 231. a Console Manager 232, a Port Manager 233, and a Debug Manager 234 
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e-*-« - s,s,em combes « «— • w Pro " ss P ~* " nd 

Theinni«l S tart-wrr.odul«oUhJoperai g „«„„,„ Template Messages. 

a^perfoU *e P-es-o ^ »J^ uro . Templ ate Message, ^ ^ ^ 

Process Manager Process, as spec y node are stored m comig modu)e 

The Resource Mmrtion Mess JBJ^ system services mus be includ^n t ^ These 

access these configuration We* p d le jn,mj and c Management 

including «e ^emen t m jncj s. ^ resource def.n. ions Jjjh- Co ^ 

^sSs ^ ones are buiit «o the start-, 

in the configuration W and toe the ^ ^ ^ ^ M 

"^configuration and ^3^^ ««— " 

invoked later at any • tm. 0> „, s conl , gur at,le at run-time. ds ,„„ Node Definition 

operating Management Process at eachn „„a,es the Resource 

As desenbed above, me u , Resource Template Ma*aa9*». ,.,,_„ , he Resource Definition 

Message for that node. ^ we., as ^»« urc , s .„„ Module « « ™^^r Modul. Is run-tlme 

't^a^or^ the feafure so, a nodedoe. ^ ^n.W, ^ ^ „ 

ae SSd«^ 

Further, both the Resource T^'f n e a other than checking for conditions message 

structures, and no ^f™*^™ presented by the Resource Template M a Reso(jrce Template 

Message files and Node Derm, ^ ^ inventjoni since 

-^hroni^^co^ 

initiated before the Me management serv.ee, w 

service - =nrinn can be specified by attribute i nformat '° n h "L ' " t be rep0 rted to the Configuration 

The proper sequencing can °f *P ma y identify events wh.ch must be repo ch ^ bQ 

Specifically, a Resource T^P 1 ^ reso y U rce accessible from other _RSM s w bej started 

Management Process .n °^ er *° ™^ n 8 t ProC ess prior to the "source Serve Mo a ^ 

sees: -rirr-^- ™ is * very ' mporta "' 

self-configurations of "° a ^ a nvenIence 0 f the reader. . f tn present invention, which 

form by FIGS. 9A-9D ,0 . r determines 
FIG. 9A shows a flowchart .1 tastrattng me in hereto , n decision block 180 ^ 

module is contained within P™| r ^ phase. If YES, the routine proceeds to D ^ ^ 

whether the resource to process, s.n^st P^^, |n dec^.on b lock 182 if tn ^ ^ 

resource is part of other g rou P s * in 
passes to decision block 186. 
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20 



25 



30 



it n n fl ^ S i° n M l °t 3 I th6 reS ° UrCe iS Part ° f 0ther 9 f0U P s the rout[ne Passes to decision block 188 If not 

are no mora resources in the list of templates, the routine proceeds to block ?89 vJhere Ee risou r^ * 6 
5 for ZXXSSSZ ^ — ™ S in *» « St ° f te P m p,ates, the rout^J^^SESrS 

to contou^ 3fter the specified ^"Chronization event has been reported 

aTcista block * ? '° < " C ' Si °" b '°'* 21 1 ' M * " v™"*"* '° *0WonS llTE 

55 but if no?'ir p ?oSd 2 r t o f bS 218 In^ 3 ^ ^o^' *' Pr ° CeedS t0 d6Cision blo <* 217. 

proceeds to decSn b ock 2« but 'i no, it If' ' ^ Cheek W3S succes ^ the routine 

60 Correlation of Flowcharts to Program Listings 
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Tnitial Hesource P rocessing 



Line Numbers in 
Program Lijsfcing A 

Resource to process in this startup phase 
Oaeck resource attributes in this node en^onine^ 
Resource definition from tenplate can be created 
New resource group to open 
Insert in list of resource groups 
Ooeck if resource is part of other groups 
Resource is part of other groups 
Instantiate resource 

More resources in list of resource tenplate 
Instantiate resource groups 



Tnstantia tA Resource 

pasource to be synchronized 

Enqueue for synchronization 

Attribute to be replaced by file content 

Substitute attribute value by file 

Process to be created exists. 

Attempt to create process 



53 


-58 






59 






59 






60 




61, 


276- 


-280 


62, 


306- 


-342 


65, 


306- 


<342 




66 




67- 


-85, 


46 



87 



Line Numbers in 
Program Listing A 

127 

128, 248-249, 221-236 

132, 606-634 

133, 637-745 
139-141 
142-144 
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Process creation successful 
More processes to create 
Process to be notified exists 

Derive resource definition message from resource 
tenplate 

Send resource definition message to process 
More processes to notify 

Check if resource is used to access core resource 
temp lates 



143-144 

138 
165-167 

177 

176-178 

164 
191-199 



Derive Resnnn^ r*£ixn_t.i_an ypc^ T 

from Re source Template 

Attributes to check in ncde definition 

Make resource message by tenplate duplication 

Duplicate resource tenplate definition 

locate attribute to check 

Valid attribute found in ncde definition 

Use found node attribute in resource message 

Remove attribute, from resource inessage 

More attributes to check 

Insert all files specified as attribute values 

Che ck Resource Attrib utes in this 

Node Environment 

ttiere is ncde feature to check 

Node feature is present in node definition 

There is bus address to check 

Probe of bus address is successful 

There is process existence to check 

Probe of process existence is successful 

Size of . compatibility has to be checked 

Size check is successful 

More attributes to check 



Line Numbers in 
Program Listing A 

477 

478 

480 
481-490 
488-496 

501 
495-499 

481 

506, 701-718 

Line Numbers in 
Program Listing 3 
64 
65-76 
90, 105, 120 
98, 113, 128 
157, 169 
158-159, 170-171 
13? 
145 
84 



wayHnS theart that the herein disclosed invention may be modified in numerous 

ways and may assume many embedments othqrthan the preferred form specifically set out anS deSed 
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PROGRAM LISTING A 



I Module • wx SI - 

" ° r ^ n ticn Creates and notifies processes about initial evaUabt 

13 Description - creates 

^ resources. 

15 - 

19 #endif 
20 

21 #include <cX.h> 

22 ^include <os/vers.h> 

23 include "config-h" . 
^include <errm.h> 

25 include <gen_codes.h> 

26 ^^**************~~**** 

27 
28 
29 



g / *^£T£Sn 9 =f — W— / 



ma — • 

31 void cmJniJnotChrdcode<tt 

32 boo I hrdcoded; 

34 ^ extern void notifyO; 

35 extern boot checkj n_g roups O, 

36 extern bool check_rsre<>; 

37 extern void new__group( ) ; 

38 extern char *res_lst; 

39 extern void r ls_groupsO, 

41 RES HD *nxt_i requeue, *prv; 

42 HSG~HANDLE handle; 

43 bool hrdc; 

^ - _ - foes HO *) res 1st; 

45 nxt_in_queue = prv - CKt:>_nu 

t! Hhl 'lJ^i^lU0n_ q ueu e ,_,FALSE); 

| *" l0N< i r intf(»resrc started XsX^Get.tripUCShandle^SS..)) ; 

51 #endif 

U if (Get_triple(&handle,HRDC,.)> c ^ truE; 

55 else hrdc = FALSE; 

l 1 f ( Chrdcoded*&hrdc) 1 1 (C I hrdcoded) &&C I hrdc) ) ) < 

59 * f (check.rsrcC&handle.) < 

59 * if ffiet triple(&handle,GRPC,_)) <• 

60 tf < Get - trip new group <&handle); 

61 ch eck in groupsC&handle) ; 

62 > - " 
63 

64 else , f - hec fc in groupsC&handle)) 

65 lf < f - chec *- in - 9 nocifyC&handle); 
66 
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What is claimed is: 
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67 
68 
69 
70 
71 
72 
73 
74 
75 
76 
77 
7S 
79 
80 
81 
82 
83 
84 
85 
86 
87 
88 
89 
90 
91 
92 
93 
94 
95 
96 
97 
98 
99 
100 
101 
102 
103 
104 
105 
106 
107 
108 
109 
110 

in 

112 
113 
114 
115 
116 
117 
118 
119 
120 
121 
122 
123 
124 
125 
126 
127 
128 
129 
130 
131 
132 



prv = nxt in_queue; 

nxt_in queue~= nxt in queue- >nxt_res; 

> 

else if (nxt in queue 1= (R£S_ND *) res_lst> < 
prv->nxt_res = nxt_in_queue->nxt_res; 
Free<nxt_in — queue) ; 
nxt_in queue = prv->nxt_res; 
> 

else 

nxt_in_queue CC££5_fiB *> res_Vst) ->nxt_res; 



else C 

prv = nxt_in_queue; 

nxt_in queue = nxt_in_queue->nxt_res; 
} 

> 

rls_groups( ); 



Instantiate Resource: 

- Create all specified service processes, if do not exist 

- Notify all specified processes, - if they do exist 



void notify(h) 
MSG_HAHOLE *h; 
C 

extern char *roejflcpyO; 
extern long NewProcO; 
extern void bad_rsrc(); 
extern char *Nxt_attrO; 
extern char *instmsg(); 
extern void to_syncnot( ); 
extern char *f i le_injrtsg(); 
extern void cm_cpen( ) ; 

extern boot^sync NIH_state; 
extern boot~sync FILE^state; 

MSGJUNDLE hi, hrep; 

char *repmsg; 

COM HECTOR ntfconn; 

char *pcrt; 

char *pntf; 

char *boot_class; 

char *upstr; 

char *tmpl; 

char *file; 

keyword *opkwd; 

char msg id CMSGI0_SI2E] , *msid; 



/* find next given attribute */ 
/* instantiate a resource message* 
/* synch notify with "!sync M msg*/ 
f* look for file triples V 
/* open a triple file */ 



/* Processjngt reply */ 
/* proc to"be notified on resrc */ 
/* process to create */ 
/* process to notify */ 
/* class of hardcoded boot device* 
/* upstr to sync with */ 
/* proc tempi name in configfile*/ 
/* file to read for triple cont */ 

/* messageid to be sent */ 



#if 10N(UNI_TRACE) . - 

printfC'Xs in notify \n",Get_tnple<h ,CLSS,_) ), 

#endif 

if (upstr = (char *) Get_triple(h, SYNC,_) ) C 
t o_syncno t ( h , ups t r ) ; 
return; 
> 

if (file = f i le^injnsgCh ,_, FALSE) ) C 



17 



0 274 406 



printf("%s port's processed \n" ,Get_triple(h,CLSS ,_)); 



133 crnopenCh,n te); 

134 return? 

135 > 
136 

137 Im"Jiandle(&h1,h->msg start, _, TRUE); 

138 while (pert = Nxt_attr(&h1 ,PCRT) ) C 

139 if (strcmp(»sratus",Crepmsg = CalKNEXT/'Processjngt", 

1*° HaJcensgC4*E-JCEYSIZE-+-strten(pcrt)+1Q, "query", "name=#s; loci", 

\)\ , Pert), , )))) i 

]fj if <<!NewProcess(pcrt, rmpV,FAlS£, 

J?£ (!Get_triple(£h1,0PTN, ))) C 

145 ~ 

146 #if 10N( UNI JTRACE) 

147 printf("Xs can not be crea ted\n" pert); 

148 #endif ' 
149 

] | ° bad_rs r c ( h , PROC _CREATE_F A I L) ; 

.Free(repmsg); 

152 return; 

153 > 

154 . y 
155 

156 Free(repmsg); 

157 > 
158 

159 mf 10NCUMI TRACE) 
160 

161 #end'if 
162 

163 Ini_handle(&h1,h->msg_start,_,TRUE); 

164 while (pntf a Nxt_attr(£h1 ,PNTF}) C 

165 lf C!stronp(»status",(repmsg = Cal I (NEXT, u Process_mgt" , 
'55 Makemsg(4*2*KEYSIZE+strlen(pntf)+10, "query", 

M name=#s; loci", J^tf >,_,_)))) £ 
1 65 I ni_handle(&h rep, r ecmsg r _, TRUE ) ; 

]f 9 ntfeonn = *(<CONNECTOR *) Get triple(&hrep, CONN,_) ); 

170 if (opkwd = (keyword *) Get_triple(h,OP!D,_) ) 

\t_\ Att_tripLe(h,*cpkwd,sizeof (ntf conn.pid) ,&ntfconn.pid); 

172 if' (msid = (char *> Get_triple(h,MSrD, )) 

J 73 strcpy(msg_id,msid); 

1 74 else 

175 strcpy(msg_id, "resource") ; 

1 76 Put ( D r RECT,&ntf conn , 

J 77 memcpy( instmsgCh ) ,msg_id, str I en(msg_id)+1 ) ) ; 

178 ((RES HD *) h->msg start) ->ntfpid = ntf conn.pid; 

179 } ~ 

180 else if C!Get_triple(&h1,OP™,_)) C 
131 

182 #if LOHCUNLTRACE) 

183 printf("Xs no process to not i fy\n" , pntf) ; 

184 #endif 
185 

bad rsrc(h,NO PROC TO NOT); 

187 > ~ - _ - 

1 88 Free(repmsg); 

189 > 
190 

191 if (Get_triple(&h1 ,SOOT,_)) C 

j 9 | boot_class = Get_triple(&h1 ,CLSS,_); 

194 if (!strcfnp(boot class , "LAW") ) 

195 . NIH_state - polled; 

19 ^ else if (i scrcmoC boot_cl ass,"disk_ctrL") ) 

197 FILE stace'= potlec; 

198 else 
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199 bad rsrc(h,BAD_BCOT J)EVJ>EF); 

200 > 

201 > 
202 

204 Synchronization notification to continue processing of a pending 

205 resource 

206 V 
207 

208 void from syncnotCsync hd,resmsg) 

209 MSG^HAHDLE *sync_hd; 

210 char *resmsg; 

211 C 

212 extern char *Mxt_attr(); 

213 extern void to_syncnot(); 

214 extern void Alt_key<); 

215 extern void notifyO; 
216 

217 MSG_HANDLE resjid; 

218 char *upst - in, *upst; 

219 boot no_more_sync; 
220 

221 upst in = Get triple(sync hd,UPST,_); 

222 Ini^handleC&ris.hd^esmsgr./NOFIXtSUSP); 

223 no more_sync = TRUE; 

224 while (upst = Nxt_attr(&resJid,SYNC) ) C 

225 if (! strong upst, upst in)) 

226 AltJeey(upst,UP); 

227 else i 

228 to_syncnot(&resJid,upst); 

229 no_more_sync = FALSE; 

230 break; 

231 > 

232 > 
233 

234 if (nojnore_sync) 

235 notify<&res_hd); 

236 Free(sync_hd->rrtsg start); 

237 } 
238 

239 /* 

240 Ask for synchronization notification that triggers continuation 

241 of processing a resource 

242 V 
243 

244 void to syncnot(h / upst) 

245 MSG_HAH0LE *h; 

246 char *upst; 

247 { 

248 PutCSELF, ,Makemsg(2*KEYSIZE+sizeaf (h->msg_start)*strlen(upst)+1 , 

249 ~ "?synch M , "upst=#s; sync^I", upst, h->msg_start)); 

250 > 
251 

252 

253 void Alt_key(v,k) 

254 char *v; 

255 keyword k; 

256 C 

257 v •= 2 * sizeof(k); 

258 *C (keyword w ) v) = k; 

259 - > 
260 

261 /* 

262 Open new resource group 

263 V 
264 
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265 void new_group(h) 

266 MSG HANDLE *h; 

267 t 

268 extern char *grp 1st; /* list of resource arouos V 
269 

270 RES HD *nxt in queue: 

271 ~ ~ " 

272 #if 10M<UHI_TRACE) 

273 printf<"Xs in new group\n"Get tripleCh }}; 

274 #endif 
275 

276 nxt_in_queue = (RES HD *) grp 1st; 

277 white (nxt_in_queue T >nxt_grp)~ 

278 nxt in queue = nxt in queue- >nxt grp; 

279 " " 

280 nxt in queue->nxt grp = (RES HD *} h->msg start; 

281 > ~ ~ 
282 

283 /* 

284 Check if a resource is a component of any group 

285 If a resource belongs to more than one group, all group resources bad 

286 */ 
287 

288 boot check_in groups (h) 

289 MSG HANDLE *h; 

290 C ~ 

291 extern boot check_in_grp(); /* check if in one group */ 

292 extern void rmv rsrcO; /* reniove resource ' */ 
293 

294 extern char *grp 1st; /* resource group list start */ 

295 " 

296 RES_HD *nxt_in_queue; /* next res group in list */ 

297 MSG__HANDL£ hi; /* current group checked */ 

298 MSG_HANDL£ hgrp; /* located group head resrc */ 

299 boot in_a_group; 

300 bool grp_rmvd; /* grouo head resrc removed */ 
301 

302 #if 10NCIINI_TRACE) 

303 pn'ntfC M %s in check in groups\n",Get tripte(h, CLSS, )); 

304 Send if ~ ~ 
305 

306 grp_rmvd = FALSE ; 

307 in a group = FALSE; 
308 

309 nxt_in_queue = ( (RES_HD *) grp 1st) ->nxt_g rp; 

310 while (nxt_in_queue) C 

311 if (nxt in queue != (RES HD *) h->msg start) C 

312 ~ " 

313 Ini handle(&h!,(char *) nxt in queue. , TRUE); 

314 * ~ - 

315 if (check_in_grp(&hl,h)) 

316 if ( I in_a group) C 

317 in_a_group = TRUE; 

318 hgrp = hi; 
319 

320 #if lON(UNI_TRACE) 

321 printf( l »%s grp head found: Xs\n n ,Get_triole(h ,CLSS,_) , 

322 Get triple(&h1,CLSS, )); 

323 #endif 
324 

325 > 

326 else C 

327 bad_rsrc(£h1 ,0OUBL£_GROU?) ; 

328 „ rrTTV rsrcCShl); 

329 if ("igrp rmvd) C 

330 bad~rsrc(£hgrp,DOuSlEj3RGUP); 



20 



0 274 406 



unsigned long marksz; /* size of the mark attribute * 

char *markg; /* P< r to mark attr in grp hd * 

char ~markc- /" ptr to mark attr in coop 

short ♦(nsnr; /* msg nr following in the grp-' 



33 1 rmv_rsrc<&hgrp); 

332 > 

333 grp_nnvd = TRUE; 

334 > 

335 > 

336 nxt_in_queue = nxt_i requeue- >nxt_grp; 

337 > " 
338 

339 if (in_a group&&! grp_rmvd) 

340 " return(TRUE); 

341 else 

342 return( FALSE); 

343 > 
344 

345 /* 

346 Check if a resource is a component of one particular group 

347 if it is, append it to, the component list of the group 
343 increment msg nr count in each component 
349 V 
350 

351 static bool check in grp(hg,hc) * * • ■ 

352 MSG HANOLE *hg; /* Srcup head handle / 

353 MSG~HANDLE *hc; /* component head handle / 

354 <: 

355 

356 RES HO *nxt in_lst; 

357 keyword keyw; /* keyw rd to mark grouo comps * 

355 
359 
360 
361 

362 long £ero; 

363 short short_zero; 
364 

365 keyw = *( (keyword *) Get_triple(hg,GRPC,_)); 

366 

367 if <markc = Get triple(hc,keyw,_) ) i 

363 markg = Get~triple(hg, keyw,&marksz) ; 

370 if <!strncmp(rnarkg,markc,(int) marksz)) { 

371 

372 #if IONCUNI TRACE) , . 

373 print f("Xs match found in check_injgrp\n",Get_tn pleChg, CLSS,J ); 

374 #endif 

376 msnr = (short *) Get_tn*ple(hg,MSNR,_>; 

377 (*msnr)-H-; 

373 Alt_triple(hg,MSNR,sizeof (short ),msnr); 
379 

330 nxt_in 1st = <RES_HD *) hg->msg_start; 

331 while Tnxt in_lsr ->nxt_ccmp) 

332 nxt_Tn_lst = nxtJn_lst*>nxt_comp; 

383 

354 nxt_in_lst->nxt_ccmp = (RES_HD -) hc->msg_start; 

385 

336 return(TRUE); 
387 > 

338 else 

339 return(FALSE) ; 

390 > 

391 else 

392 returnC FALSE); . 

393 > 
394 

395 /* 

396 Release all group lists, create and notify all related processes 
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397 (each resource is assumed to have been checked on exi stance) 

398 */ 
399 

400 static void rls_groupsO 

401 C 

402 extern void notifyO; 

403 extern void rls_grp(); 

404 extern char *grp^lst; /* list of resource groups 
405 

406 MSG_HANDLE h; 

407 RES_HD *nxt in 1st; 
408 

409 nxt_in_lst = <(RES_HD *) grp_tst)->nxt_grp; 

410 while (nxt_in_lst) { 

411 Ini handle(&h,nxt_in lst,_,TRUE); 
412 

413 #if LOHCLIMI_TRACE) 

414 printfC'Xs in rls_groups\n",Get_tripte(&h,CLSS,_) ) ; 

415 Sendif 
416 

417 if (!CCRES_H0 *) h.msg_start)->ntfpid) 

418 rls_grp(&h); 
419* nxt__in 1st = nxt_in_lst->nxt_grp; 

420 > 

421 ' > 

422 . 

423 static void rts_grp(hg) 

424 HSG__HANDLE *hg; 

425 C 

426 extern Yoid notifyC); 
427 

428 MSG — HANDLE h; 

429 RES HD *nxt_in 1st; 
430 

431 nxt_in_lst = (RES_HD *) hg->msg_start; 

432 while 7nxt_Jn 1st) C 

433 . Ini handle<&h,nxt_in_lst,_,TRUE); 

434 notTfyCSh); 

435 nxt in 1st = nxt in lst*>nxt_coap; 

436 y ~ ~~ ~ 

437 > 
438 

439 /* 

440 Get next field with same keyword from a standard cX message 

441 (brand new handle assumed at the 1st call, 

442 no external Nxt triple expected between calls ) 

443 */ 
444 

445 char *Nxt attrCh,keyw) 

446 MSG_HANDLE *h; 

447 keyword keyw; 

448 < 

449 char *value; 

450 keyword k; 
451 

452 while (value = Nxt_triple(h,&k,_)) 

453 if (k = keyw) 

454 return(value); 

455 return(MJLL); 

456 > 
457 

458 /* 

459 Instantiate a message (define node -defendant attributes) 

460 */ 
461 

462 char *instmsg<h) 
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463 MSG_HANDL£ *h; 

464 C 

465 extern char *dupmsg(); 

466 extern boo I attrjiameO; 

467 extern unsigned long Si ze_triple( ); 
466 extern char *Nxt_attr( ); 

469 extern void ins fileO; 

470 

471 extern RES_H0 'node res; 

*472 

473 MSG_HANDLH h0, hi , h2; 

474 keyword *attr_ref , *attr_def; 

475 char *attr vaT; ~ 
476 

477 if C(!Get_triple(h,SBST,_>) && ( !Get_triple(h , FHRP,_)) ) 

478 return(dupmsgCh->msg start)); 
479 

430 IniJiandleah0 / dupnsg(h->msg_start) #- ,W3FIX|SUSP); 
481 while (attr ref = (keyword *) Nxt_attr(4hO f SBST)) C 

462 if <latTr_naroe<(char *) attr_ref)) 

433 " continue; 

484 Ini_handle<&h1,h->msg start,_, FIX (SUSP); 

485 while (attr_def = (keyword *) Hxt_attr(&h1 ,*attr_ref )) C 

486 if (!attr_n3roe((char *) attr_def)) 
437 continue; 

£88 else if (!node_res) C 

489 Del^tripleC&hO^attr^raf ); 

490 continue; 

491 > 
492 

493 Ini handle<&h2,node_res,_,FIX|SUSP); 

494 if <!(attr_val = Nxt_attr(&h2 r *attr_def ) )) C 

495 Del_triple(&hO,*attr_ref ); 

496 continue; 

497 > ' 
498 

499 while (Del tripleC&hO, *attr ref)) 

500 

501 Add_triple(&hO J *attr_ref ,Si2e_triple(attr_val),attr_val); 

502 break; 

503 ) 

504 > 
505 

506 ins_f ile<&h0); 

507 ret urn(h0.msg start); 

508 > 
509 

510 r 

511 Duplicate a message 

512 V 
513 

514 char *dupmsg<msg) 

515 char *msg; 

516 C 

517 extern char *menicpyO; 
518 

519 char *newmsg; 

520 unsigned long size; 

521 MSGINFG msginfo; 
522 

523 • Msg_info(msg,&msginfo); 

524 return(memcpy(Al loc(msginfo. size) ,msg, msginfo. size)) ; 

525 > 
526 

527 /* 

528 Return size of a triple 
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529 V 
530 

531 static unsigned long Si ze_triple<val ) 

532 char *val; 

533 C 

534 val -= sizeof (keyword) ; 

535 return(*(( unsigned long *) val)); 

536 > 
537 

538 /* 

539 Check if triple refers to an attribute name 

540 */ 
541 

542 static boot attr_name(val ) 

543 char *val; 

544 < 

545 extern unsigned Long Size_tripleO ; 

546 extern boot allasciiO; 
547 

548 if (Size_triple<val) != sizeof (keyword)) 

549 returnC FALSE); 

550 else 

55 1 returnC a 1 1 asci i ( va I , s i zeof ( keyword) ) ) ; 



552 > 
553 

554 static boot al Lasci i (p, k) 

555 char *p; 

556 int k; 

557 C 

558 extern bool my_isascnO; 
559 

560 bool all_ascii; 

561 int i; 
562 

563 all_ascii = TRUE; 

564 for <i=0;Hk;i++) 

565 if (!my_isascii(*(p+i))) 

566 " all_ascii = FALSE; 
567 

568 return(all_asci i ); 



569 y 
570 

571 static bool my__isasci i (c) 

572 char c; 

573 C 

574 if C (c>0x1f) && (c<0x7f) ) 

575 return(TRUE); 

576 else 

577 return(FALSE); 

578 > 
579 

580 /* . 

581 Routines to replace file reference triples with file content 
582 

583 file__in_msg(h) * look for file triples 

584 cm_open(h,f i le) - open triple file 

585 cm_read<ch, conn) - read a triple file 

586 mct_triple(rh,conn) • mark a triple file as read and close it 

587 ins file(h) - insert all marked triple files in res msg 

588 cm_fmgt_err(fmh) - check if "failed" is a triple file error 

589 */ 
590 

591 static char *f i le_in_msg(h, keypp,af ter_read) 

592 MSG_HANDLE *h; 

593 keyword *keypp; 

594 bool after_read; 
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596 extern cnar *Nxt_at t rO, 

597 extern boot attr^nameO; 

5 98 extern boot allasciiO; 

599 extern void AltJceyO; 

601 MSG_HANDLE h0, M; 

602 keyword file; 

603 keyword *attr_ref; 

604 char *path; 
605 
606 
607 



if (!after_reed) 

file = FILE; 

60S etse 

609 file 9 FILG; 

611 * if <Get_triple<h,fUe,_>) < BT v!«i«spv 

6 2 Ini handleC&hO^^msg.start.^FIXlSUSP), 

6 | while (attr ref - (keyword *) Nxt_attr<&hO, f i le» 

6U " Cl.«rj»«.<<char •) -"r^ref)) 

615 

*\$ Ini handleCtt^h-^start^.FIXlSUSP); 

6 8 ^ile (path * Nxt_attr(&h1 *attr ref > 

a o H «allasciiCpath,strlef*path))> W 

619 (*path « V) (strlen(patb) > 2>) C 

I?? if (after read) 

621 A U_key<attr_ref,MFIL); 

623 eUe AU key(a «r_ref,FIL0>; 

625 *keypp » *attr_ref; 

return (path); 

62S , * 

629 else 

continue; 

631 3 

632 > 
633 

634 return(MULL); 

635 > 
636 

637 static void cm_open<h, f i le) 

633 HSG_HANDLE *h;~ 

639 char *file; 

640 t 

641 char *opmsg; 

642 „ - y a ^« n /yTMq!ZE+3*2*KEYSIZE+strlen(f i le)+12, "open", 
™ K ' l name=#s; oood=#s; amod-^s , me, k , * 

645 Msg_partn(ocmsg, (char *) h- >msg_start ) ; 

646 Put (NEXT, 1 * ilejngt", opmsg); 

647 > 
648 

649 void cm read(h,conn) 

650 MSG_HANDLE *h; 

651 CONNECTOR *conn; 

652 < . . ... ... 

653 extern void read_file<), 

654 * ;i- /h ( . n nn^• /* same as in Process jngt */ 

655 read_f i le(h, conn), ' 

656 > 
657 

658 void met triple(h,conn) 

659 MSG^HANDLE *h; 

660 CONNECTOR »conn; 
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661 C 

662 extern void close fileO; /* same as in Processjngt */ 

663 extern char *f i Le^in^msgC ) ; /* find first *ile triple value V 

664 extern void AltJceyO; /* change key field of a triple V 

665 extern void bad rsrcO; /* change key field of a triple */ 
666 

667 MSG INFO msgfnfo; 

668 MSG_HANDLE reshndl; 

669 char *resmsg, *path, *filel; 

670 keyword keyp; 
671 

672 Msg_inf o(h->msg_start,&nsginfo) ; 

673 resmsg - (char *) msginfo.tag; 

674 Ini handle(&reshndl r resmsg, ,SUSP|HOFIX); 
675 

676 cLose_f i le(h,conn); 

677 path = f i le_in_msg(&reshndl ,&keyp f TRUE) ; 

678 Add triple<h,KEYP,sizeof(keyp) r &keyp); 

679 *((char-**) path) = h->msg_start; 

680 Alt key(path,FMRP); 
681 

682 if C!Get_tripleC&reshndl f FIl_O f _)) 

683 if (lGet_triple<&reshndl f BADF f _>) 

684 notifyC&reshndl); 

685 else 

686 bad rsrcC&reshndl , FILE_READ_ERROR) ; 

687 > 
688 

689 static void ins_file(h) 

690 MSGJiANDLE *h; 

691 C 

692 extern void AltJceyO; 
693 

694 HSG_HANDLE hres, hfmrep; 

695 char *fmrep, **fmrepp; 

696 char *fdata; 

697 char *fptr; 

698 unsigned long fdsize; 

699 keyword *keypp; 
700 

701 if <Get_triple(h,FMRP, )) C 

702 Ini handle(£hres,h~>msg start, _,FIX|SUSP); 

703 while (fmrepp = (char Hxt_attr(&hres,FMRP) ) C 
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Inl fdaTa = Get triple(&hfmrep,DATA,ifdsize); 

*S keypp = (keyword -> Get^tnpLe(&hfnirep,KEYP,_) ? 

7 7 % Ado_?rJpte<h.-keypp,fdsTze r fdat a ); 

70 9 Free(fmrep); 

710 > 

HI tni h a ndi e (&hr eS ,h->msg start FUISUSP); 

714 ~ 

™ Inf handte<&hres,h->msg start FIX|SUSP); 

7 \j while (Del_triple(&hres,FMRP)) 

718 

719 > 

720 > 

722 boot cm fmgt_err( fnri) 

723 MSG_HAHDLE *fmh; 

724 C ~ 

725 extern char *f Ue_in_msg<); 

726 . . 

727 HSGIMFO msginfo; 

728 HSG_HAHDLE reshndl; 

729 char *resmsg / *path, *req; 

730 keyword keyp; 

^2 req = Get_tri ple(fmh , REQ , — ) ; 
734 

£!f Hsg info(fmh->msg_start,&nsginfo); 

737 resmsg = (char *) msginf o. tag; 

741 returnCTRUH); 

742 -v 
743 

744 

745 return( FALSE); 

746 > 
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Module ; %M% %I% 

Date submitted : XEX %U% 

Author : Gabor Simor 

Origin : cX 

Description : Configuration Management Error Handling Rout ins 



#ifndef lint 

static char Srcldfl = "XZXZMXiXlW 1 ; 
#endif. 

^include <cX.h> 
^include <os/vers.h> 
^include "config.h" 
#include <errm.h> 
^include <gen_codes.h> 



V 



Check if resource available and if its attributes are consistent 
with the environment 



V 



booL check_rsrc(hl 
MSG_HANDLE *h; 
< 

extern void bad_rsrc<); 
extern boo I comptbl_size< ) ; 
extern char *Nxt_attr() ; 
extern char *instmsg(); 

extern R£S_HD *node_res; 

char *chck; 
char *badr; 
char *size; 
char *res_feat; 
char *p_name; 
char *repmsg; 
char *node_feat; 
boot resolved; 
MSG_HANDLE hO, M, hsub; 
int dontcare; 



/* attribute to check */ 

/* bus address */ 
buffer size of conns protocols */ 

/* node feature to be checked */ 

process name to be checked */ 

reply message from Proc_mgt */ 

node feature found */ 

if current feature resolved */ 



/ 



Ini_handle<&hsub / instmsg(h) # _ / FIX|SUSP); 

#if lOWCUNr TRACE) 

princf<"Xs in check_rsrc\n",Get_triple{h,CLSS / _)); 
#endif 



check if associated node feature required 



Im*JiaridleC&hO",hsub.msg_start,_, FIX | SUSP) ; 
while (res_feat = Nxt_attrC£h0, FEAT) ) C 
if (!node_res) C 

FreeChsub.msg start); 
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if <*C(long *) chck) = BADR) C 



67 recurnC FALSE); 

65 ) 

69 resolved = FALSE; 

70 Ini_handle(&h1 ,node_res,_, F IX | SUSP) ; 

71 while <node_feat = Nxt_atrr(&h1 , FEAT) ) 

72 if ( !stranp(node feat7res_f eat ) ) ^ 

73 resolved =~TRUE; 

74 break; 

75 > 

76 if (! resolved) C 

77 Free(hsub.msg_start) ; 

78 returnC FALSE); 

79 > 
SO > 
81 
82 

83 Ini _handl e(&hO , hsub.msg_start FIX | SUSP ) ; 

84 while (chck = Nxt_attr(&hG,CHOO ) i 

as 

86 /* 

87 check on bus address existence 
38 V 
89 
90 
91 

92 #if LOHCUNt TRACE) . 

93 " princfC'Xs to be- checked on BADR\n'\Get_triple<h,CLSS,_) ); 

94 #endif 
95 

96 Ini handle(&h1,hsub.msg start, _,FIX|SUSP); 

97 while "Cbadr = Nxt_attr(&h1 , BADR)) 

or if (iHprobe<HP RDB *( (unsigned long *) badr),&dontcare) ) C 

99 " bad_rs re (h, BADR _N ON EXT); 

1Q q ' Free(hsub.msg_start); 

-j Q1 returnC FALSE); 

102 > 

103 > 
104 
105 
106 

107 tfff LOHCLINT TRACE) . i ^ _ f ^ ^ 

108 " printf<"%s to be checked on BADR\iV\Get_triple<h,CLSS f _.>.); 

1 09 #end i f 
110 

111 Ini_handte(&h1,hsub.msg start, _,FIX|SUSP); 

112 while (badr = Nxt_attr<Sh1 , YAOR) ) 

if (iMprobeCMP ROB *( (unsigned long *) badr ) ,&dontcare) ) C 
\\l bad_rsrc(h,BADR_NOWEXT) ; 

Free(hsub.msg_start); 
« 16 return( FALSE); 

117 > 

118 > 
119 
120 
121 

122 #if IONCUMI TRACE) . ^ „ ^ >s 

123 ~ printfO'Xs to be checked on BA0R\n",Get_tnple(h,CLSS,_)); 

124 #endif' 
125 

126 Inijiandle(&h1,hsub.msg start, FIX | SUSP) ; 

1?7 while (badr = Nxt attr(&hl , NADR) ) 

i? a if (HprobeCHP ROB , »( (uns i gned long ») badr) ,&dontcare) ) < 

~ bad_rsrc(h,BADR_EXIST) 
13 q FreeChsub.msg start); 

^ . return< FALSE)? 

132 y 



else if (*((long *) chck) == YADR) C 



else if ("((long *) chck) == HA0R) C 
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133 > 
134 

135 /* 

136 check on consistency of size attributes 

137 V 
138 

139 else if <*<(Lcng *) chck) == SIZE) 

HO if ([(size = Get tripte(h,SIZE, ))) C 

141 " bad_rsrc(h,NO_SIZE_TO_CHECK); 

142 Free(hsub.msg_start); 

143 return(FALSE); 

144 > 

145 else if Clcomptbl si ze(h f *C< long *) size))) C 

146 " b*d_rsrc<h,rNCOMPTBL_SIZE); 

147 FreeChsub.msg start); 

148 return(FALSE)7 

149 > 

150 > 
151 

152 /* 

153 check if process exi stance conditions satisfied 

154 */ 
155 

156 IniJ]arxile<&h1,hsub.n«g_start,_,FIX|SUSP); 

157 while <p_naroe = Nxt_attr(&h1,PROO) 

158 if (strcinpC "status", (repmsg - Cal UNEXT, "Process_tngt M # Makemsg 

159 <H*2*KEYSIZE+strlen<p_name)-H , "query", !, name#s; loct" ,p_name), , 

160 bad_rsrc(h,PROCJfONEXT); 

161 FreeChsub.msg^start); 

162 Free(repmsg) 

163 return(FALSE); 

164 y 

165 else 

166 Free< repmsg) ; 
167 

168 Ini_handle(Sh1 r hsub.msg_start,_ # FIX|SUSP); 

169 while (p_name = Nxt_attr(£h1 ,NPRC)) 

1 ?a if CstrcmpC'fai led", (repmsg = Ca 1 1 (NEXT /'Process jngt",Makefnsg 

1^1 C2*2*KEYSIZE+strlen(p_name)+1 / »query»,"name#s; locl»,p name), , 

1^2 bad_rsrcCh,PROC_EXISTT; 

173 Free(hsub.msg_start); 

174 - FreeC repmsg); 

175 return(FALSE); 

176 > 

177 else 

178 Free (repmsg); 
179 

180 FreeChsub.msg^start); 

181 return(TRUE); 

182 > 



Claims 

1. In a distributed data processing system comprising a plurality of interconnected nodes (170-174, 
FIG. 7), at least one of said nodes (170) comprising a set of resource configuration rules for configuring 
resources on any node of the system, a method of configuring resources for a specific node of said 
system (171), said method comprising the steps of: 

a) providing to said specific node a resource definition message ; and 

b) utilizing said resource definition message to configure a resource sever module for each 
resource type needed by said specific node. 

2. The method of configuring resources recited in claim 1 , wherein said resource definition message is 
derived from a resource template message which defines the attributes of a resource for all anticipated 
node environments. 

3. The method of configuring resources recited in claim 2, wherein a plurality of resource template 
messages provide said set of resource configuration rules for said system. 

4. The method of configuring resources recited in claim 1, wherein said one node comprises a plurality 
of resource server modules. 

5. In a distributed data processing system comprising a plurality of interconnected nodes (170-174, 
FIG. 7), a method of configuring resources for one of said nodes (171), said method comprising the steps 
of: ■ < . .-^ c , " 

a) providing in said one node a configuration management process; 5^v% v 
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b) providing to said one node a node definition message which defines a configuration for said one 
node; 

c) providing to said one node a plurality of resource template messages which represent a set of 
generic configuration rules; 

d) using said configuration management process, said node definition message, and said 5 
resource template messages to create a resource server module for each resource type required by 

said one node; 

e) providing to said resource server module a resource definition message; and 

f) using said resource definition message to configure said resource server module. 

6. The method of configuring resources recited in claim 5, wherein said node definition message is w 
derived from a node template message which defines the possible attributes of a node for all anticipated 
types of nodes in the system. 

7. The method of configuring resources recited in c/aim 5 t wherein said resource definition message 
can be derived from a resource tempiaie message which deftnes Wie possitofe attributes of a resource for 

all anticipated node environments. 15 

8. The method of configuring resources rec/ted in claim 5, wherein said resource definition message is 
generated by an expert system in response to at least one resource template message and at least one 
node definition message. 

9. The method of configuring resources recited in claim 5, wherein said resource template message is 
generated by an expert system. 20 

10. The method of configuring resources recited in claim 5, wherein said node definition message is 
generated by an expert system. 
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